fix(signals): rank issue-quality report before capping to 100 - #2366
Conversation
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-01 19:01:26 UTC
⏸️ Suggested Action - Manual Review Review summary Nits — 3 non-blocking
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2366 +/- ##
==========================================
+ Coverage 95.71% 95.74% +0.02%
==========================================
Files 222 222
Lines 24653 24654 +1
Branches 8945 8945
==========================================
+ Hits 23597 23604 +7
Misses 433 433
+ Partials 623 617 -6
🚀 New features to boost your workflow:
|
Summary
buildIssueQualityReportinsrc/signals/engine.tscapped the open-issue list to the first 100(
issues.filter((issue) => issue.state === "open").slice(0, 100)) before scoring and sorting byscore. Once a repo has more than 100 open issues, whichever 100 happen to be first in the caller's
input array (not necessarily the highest-quality ones) are the only issues ever scored — a genuinely
stronger issue sitting past position 100 is dropped from the report entirely, even though it would
outrank most of the retained 100.
ISSUE_QUALITY_REPORT_CAP = 100constant, matching the existing
MAX_COLLISION_PAIRWISE_ISSUES/ISSUE_DISCOVERY_LIFECYCLE_REPORT_CAPstyle), and updates the stale perf comment above it ("runs over up to 100 open issues" -> "runs over
every open issue") since the per-issue indexes built just above already make the loop
O(issues + PRs), so scoring every open issue instead of a pre-capped 100 is unaffected performance-wise.
.gittensory.ymlsetsissueDiscoveryPolicy: discouragedandlinkedIssuePolicy: preferred(not required). This is a small, self-contained, self-evident fixconfined to one file plus its regression test.
Scope
type(scope): short summaryConventional Commit format, for examplefix(api): restore profile access checks.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.Validation
git diff --checknpm run actionlintnpm run typechecknpm run test:coveragelocally;codecov/patchrequires >=99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.npm run test:workersnpm run build:mcpnpm run test:mcp-packnpm run ui:openapi:checknpm run ui:lintnpm run ui:typechecknpm run ui:buildnpm audit --audit-level=moderateIf any required check was skipped, explain why:
npm run test:cichain on this Windows dev machine stops attest:coveragebecause of a fixed set of pre-existing, environment-only failures unrelated to this diff: a CRLF-vs-LF mismatch from a Windowscore.autocrlfcheckout (gittensory-focus-manifest.test.ts), missingclaude/codexCLI binaries on PATH (selfhost-ai.test.ts), a libuv/Windows subprocess assertion in thegittensory-mcpCLI test harness (mcp-cli-doctor.test.ts,mcp-cli-profiles.test.ts), and a couple of tests that are flaky under full-suite parallel load but pass individually (mcp-output-schemas.test.ts, onemcp-cli-doctor.test.tscase). None touchsrc/signals/**or the changed test file. The targeted suites for this change (issue-quality.test.ts,signals.test.ts,signals-coverage.test.ts) pass cleanly andtsc --noEmitis clean. I did not reachtest:workers/build:mcp/ui:*locally because the&&-chainedtest:ciscript stops at the first failing step; this PR does not touch workers, MCP packaging, orapps/gittensory-ui/**, so those steps are unaffected by the diff.Safety
UI Evidencesection below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.If any required check was skipped, explain why: this PR has no auth/CORS/session surface and no UI change, so those boxes are not applicable.
Notes
test/unit/issue-quality.test.ts) with 110 low-scoring filler issuesfollowed by one high-scoring issue placed past the old cap boundary, asserting the strong issue is
ranked first in the returned 100. I confirmed this by reverting the source change locally and
observing the new test fail with the strong issue dropped and a low-scoring filler issue returned
first instead.